@woodruffw we should probably drop that experimental note from the README. Looks like it's long overdue...

i don't understand how it would be considered stable when the failures as described in #365 are still occurring and from what i gather from skimming over the following discussion nobody really knows the cause(s).

@funkyfuture that was resolved in a day or so. I just haven't had a chance to close that issue, because I wanted to track a few follow-up discussions. The bug is known. It was in PyPI's dependency and that's addressed. There was also a standardization issue that's documented in PyPUG now.

There haven't been any other reports. I don't know where you're getting those imaginary breakages that are "still occurring" — I haven't seen a single proof of that.
If you saw some unexpected happening somewhere, you should start by reporting that as an issue instead of trying to silently disable security-related features for literally every user of the action.

You could as well argue that the entire Trusted Publishing thing should be reverted because there were bugs along the road and I would say that nothing is stopping you from going back to using API tokens 🤷‍♂️ and keeping your uploads less transparent.

That said, there's no merrit in disabling attestations. This will remain secure by default. But we should update README. Such a PR would be very welcome indeed.

Yeah, the feature is de facto no longer experimental (and de sure, in the sense that it's tied to a fully accepted PEP). I'll own updating the documentation to clarify that.

Done with #371; the PyPI docs also still say "experimental," so I'll send a PR to update those later today.

e: pypi/warehouse#18450

There haven't been any other reports. I don't know where you're getting those imaginary breakages that are "still occurring" — I haven't seen a single proof of that.

i encountered it yesterday.

and i didn't report it redundantly as #365 describes that and is still open. particularly this note leaves the impression that it is unclear whether the fixes actually solved the causes.

i encountered it yesterday.

That's a different error; the original issue is specifically about a filename matching/normalization bug, not about any and all errors that can happen while verifying an attestation.

In your case, it looks like you have your Trusted Publisher set up against build-and-publish.yml, but you signed an attestation from maintenance-update.yml. I'm not exactly sure why that surfaced as an attestation failure rather than a higher-up mismatch, but it's a different root cause than #365.

Oh, that's because reusable workflows aren't officially supported, pending a fix in PyPI. It works for one obscure corner case for some people by accident. But a bugfix in Warehouse (PyPI) is required and it won't be backwards compatible with hacks that made it possible for said corner case. This isn't really an attestations thing but Trusted Publishing as a whole (the OIDC layer to be precise). We've spent hours at the PyCon US sprints in May strategizing the migration and it's recorded somewhere in a Warehouse issue. I believe Facundo is still waiting for funding to complete that work.

TL;DR is that your use is unsupported, but the supported uses are functional and stable.

Ah yeah, I think this is a (new) edge case where the reusable workflow handling is rough: the attestation is from maintenance-update.yml, so dispatching into build-and-publish.yml as your TP identity results in the unsupported scenario @webknjaz mentioned, plus a mismatch between the attestation and the actual uploading identity (which PyPI then detects).

@woodruffw I'm pretty sure I saw this case earlier. I was hoping you PR #306 with hints would steer people in the right direction..

Okay, that gives me more incentive to revive that PR. I'll try and get to it this week 😅

thank you for your hints and elaborations. from a user perspective i'd like to leave some remarks:

• i would not consider the use of nested workflows an edge case
• i see that state of affairs is discussed here, but honestly without the discussion here it would have taken me a frustrating while longer to infer that this is relevant information for my case
• imo it also strongly contrasts with this guide that i consulted for the initial setup and troubleshooting
  • the lack of support for modularized workflows isn't mentioned there
  • the statement "you must provide … the filename of the GitHub Actions workflow that's authorized to upload to PyPI." would generally be ambiguous, i intuitively assume it refers to the workflow filename where the upload Action call is defined, not the initial workflow
• it's frustrating to learn that a workflow that was once working only did so by chance
• the recommended workaround that is stated in the README is not suited in the my referenced case
• surely any improvement of error messages is highly appreciated, i actually didn't pay much attention due to the noise

No problem, thanks for providing more details.

• the lack of support for modularized workflows isn't mentioned there

It's mentioned here: https://docs.pypi.org/trusted-publishers/troubleshooting/#reusable-workflows-on-github

I suppose we could probably link to the troubleshooting page in more places; it probably makes sense to have this action include it as part of the diagnostic output.

• the statement "you must provide … the filename of the GitHub Actions workflow that's authorized to upload to PyPI." would generally be ambiguous, i intuitively assume it refers to the workflow filename where the upload Action call is defined, not the initial workflow

I agree, although your intuition here unfortunately doesn't match GitHub's security model: a reusable workflow can be reused by anybody including forks and arbitrary repos, so it can never be used to uniquely identify a CI/CD run for something like Trusted Publishing. So PyPI can never rely solely on the reusable workflow identity; it must always use the caller identity in some form, since that's grounded against the repository.

That's something we could definitely improve the documentation for however, since GitHub doesn't (IMO) do a great job of explaining that.